Merge pull request 9305

Merge pull request 9304

This reverts commit 73fcc42.

Merge pull request 9292

Merge pull request 9326

To appease RuboCop `Minitest/AssertInstanceOf`

Merge pull request 9360

…n list (#9376)

Merge pull request 9376

Merge pull request 9361

Merge pull request 9401

Merge pull request 9405

Merge pull request 9406

…icle (#9411)

Merge pull request 9411

Merge pull request 9392

Merge pull request 9832

Merge pull request 9850

Merge pull request 9867

Merge pull request 9882

Merge pull request 9889

… limit parameters (#9912)

Merge pull request 9912

Merge pull request 9897

Merge pull request 9923

Merge pull request 9920

Merge pull request 9914

Merge pull request 9925

Merge pull request 9954

Merge pull request 9960

This is a 🙋 feature or enhancement. 
This is a 🔨 code refactoring. 

## Summary

Improve and streamline our release processes with some extra automation
and a bit more rigor around PRs/commits.

## Context

With Jekyll 4.4 released, and under the assumption that the next release
will indeed be 5.0, I think it makes a lot of sense to take some time
and evaluate our development practices and streamline the process of
shipping. We generally go a long time (four months between 4.3.4 and
4.4.0, two years between 4.3.0 and 4.4.0) between releases and this is
my attempt at trying to improve that. While this PR is currently
incomplete, if there's interest in going this direction, I'll make time
over the next few days to clean it up and get it ready to actually ship.

In order to do this, I'm relying on the
[`release-please`](https://github.com/googleapis/release-please-action)
action from Google to do the majority of the heavy lifting. Please read
the release-please README in order to learn how release-please works and
what it does. In order to make it easier to adopt release-please, I've
made two additional changes. ~~The first is to rename `History.markdown`
to `CHANGELOG.md` since that's what `release-please` works with out of
the box.~~ The other is to add two new github actions workflows to run
release-please and to enforce conventional commit conventions on PR
titles. Because we squash merge, the PR title becomes the commit message
and `release-please` uses the commit messages to know when to bump the
version number.

One potential caveat with this is that it may become harder to maintain
stable branches. My point of view on this is that we've done a
relatively poor job of maintaining them regardless and I think it's more
important to release often, even if we end up bumping major or minor
version numbers more frequently than before. My stance on this is that
version bumps have no inherent goodness or badness. They are a
communication mechanism. We should let go of having to wait a certain
amount of time to do major version bumps or avoid work because it would
cause a major version bump, for example.

### Process changes

The use of release-please means that we can stop using jekyllbot to do
the merges and update History.markdown for us, as release-please will
take care of that when we cut the release. We will also no longer need
labels on PRs as the use of conventional commits will explain exactly
what is changing.

The process for releasing becomes:
 - Merge the docs PR
 - Merge the automatically generated release-please PR, which will
trigger the workflows to do the tagging, releasing, gem publishing, etc.

### Remaining work to do:

- [x] Change the pull request settings to only allow squash merges, as
jekyllbot enforces this for us today.
- [x] ~Update the site publishing process to pull from `CHANGELOG.md`
instead of `History.markdown`~ No longer needed.
- [x] Integrate jekyllbot into release-please (the release-please PRs
will be made by jekyllbot). This allows actions to be triggered on the
release-please PRs.
 - [x] Test the workflows to make sure they generate a PR correctly.
 - [x] ~Integrate the release publishing workflow into release-please
when it creates a release.~ Happens automatically with the existing
workflows.

This is a 🐛 bug fix.

## Summary

The `release-please.yml` workflow doesn't make sense in forked
repositories. Let's restrict its execution to jekyll/jekyll only.

I did not expect a "workflow failed" notification soon after catching up
with the upstream in my forked repo:

<img width="1542" height="961" alt="image"
src="https://github.com/user-attachments/assets/5049f2ca-1b1b-42b8-b6ea-4c91ce66a6c3"
/>

This is a 🔦 documentation change.

## Summary

The install documentation for WSL offers to install Ruby through
BrightBox. However, BrightBox does not support Ubuntu Jammy (which is
the default for latest WSL builds). Instead, this commit just redirects
the WSL user to the Ubuntu installation procedure to avoid duplicate
documentation.